Spørgsmål/svar om borgerkontaktløsningen

Her kan du finde svar på de oftest stillede spørgsmål om borgerkontaktløsningen.

Hvis du har spørgsmål som ikke er besvaret her, kan du sende dem til Pernille Østerbye på mail: pop@kombit.dk

Vi kigger på vores egne KOMHEN tal her i Vejle i forhold til business casen. I den forbindelse bliver vi i tvivl om jeres definition af hhv. en ”transaktionshenvendelse” og en ”informationshenvendelse”.
Vi har i KOMHEN registreret på 6 henvendelsestyper. Hvilke er hvad?

1)    Oprettelse af ny sag = transaktionshenvendelse
2)    Information om eksisterende sag = informationshenvendelse
3)    Ændring af status på eksisterende sag = transaktionshenvendelse
4)    Råd og Vejledning = informationshenvendelse
5)    Hjælp til selvbetjening = informationshenvendelse
6)    Fejlhenvendelse = informationshenvendelse

Hvilken platform forventer I at anvende til borgerkontaktløsningen (Open Source eller?)?

Dette vil afhænge af, om leverandøren kan levere software som Open Source. KOMBIT har ikke på forhånd lagt sig fast på, om løsningen skal laves som Open Source. Det må være op til netværket, at beslutte om man ønsker dette, hvis det kan lade sig gøre.

Har man tænkt på snitflader til kommunens hjemmeside i øvrigt? Her tænkes på f.eks. medarbejdersøgning, høringer osv. – (Vil det blive en hjemmeside i hjemmesiden)?

Vi er opmærksomme på problematikken. Man må i netværket drøfte, hvordan en borgerkontaktløsning bedst kommer til at fungere på kommunens hjemmeside. Målet bør være, at al borgerbetjening kan foregå via en borgerkontaktløsning - ikke kun de områder som traditionelt har været varetaget af borgerservice.

Er business casen rent baseret på at flytte henvendelser (kanaler)? I så fald vil man måske også kunne gøre det ved en anden hjemmeside og integrationer til fagsystemer.

Det er korrekt, at BC udelukkende fokuserer på kanalflytning. Der er en række andre nytteværdier, som vi også har beskrevet i vores oplæg, men de indgår ikke i beregningerne. Vedr. om man kan anvende anden hjemmeside, altså om man kan bruge kommunens hjemmeside til at lave kanalflytning: Vores vurdering er, at det kan man godt, men ikke lige så effektivt som med en kontaktcenterløsning, som også håndterer andre kanaler end hjemmeside, f.eks. chat, click to call og co-browsing.

Er den tænkte løsning det, der svarer til KVIKKEN og tilhørende back end system (se på kk.dk)?

Ja, det er samme løsning.

I hvor stor udstrækning kan man tilføje lokalt indhold til den tænkte CMS – kan man f.eks. indsætte sider eller menuer, der er helt lokale (det kunne f.eks. være en kampagneside eller lignende)?

Ja, det er muligt at tilføje lokalt indhold. Vi er ikke bekendt med, om der er nogle begrænsninger.

Angående antal henvendelser og fordelingen heraf: Jeg har set på de tal, som pt. ligger tilgængelige på KL’s digitale landkort gældende hele landet og med data fra KOMHEN 2.0. Og her er fordelingen som nævnt. Hvis fordelingen i stedet er 50/50, ligger det stadig et godt stykke fra den fordeling, der er nævnt i KOMBITs oplæg. Så når du vurderer, at de nye tal under alle omstændigheder vil påvirke business casen positivt, skyldes det, at det totale antal henvendelser er tilsvarende større. Er det rigtigt forstået?

Vi kan kun tage udgangspunkt i de officielle tal fra KOMHEN, som netop er som fremlagt. Det er klart, at en evt. forskydning mellem de henholdsvis transaktions- og kommunikationshenvendelser vil forskyde BC.

Angående kanalpriser: I vil nedjustere omkostningsforskellen (mellem en telefonisk henvendelse og en selvbetjeningshenvendelse) fra 35 til 31 kroner. Dermed lægger I kanalprisen for en automatisk selvbetjeningshenvendelse til grund. Hvordan forholder I jer til, at hovedparten af de nuværende selvbetjeningsløsninger ikke er automatiske og derfor medfører en omkostning på 19 kroner pr. henvendelse (ifølge Devoteam Consulting/KL)?

Vi justerer naturligvis tal for en tlf. henvendelse til trods for, at stort set alle andre beregninger herunder tal fra FM , viser en langt højere pris. Med hensyn til tal på en selvbetjening via nettet, så har man i Devoteam-rapporten taget afsæt i en kanalpris regnet på, hvad det i dag koster pr. transaktion med de omkostninger, man har til selvbetjeningsløsninger. Det retfærdiggør på ingen måde potentialet, men fortæller blot, at alt for få lige nu og her bruger de enkelte løsninger, hvorfor stykomkostninger bliver forholdsvis høj. Det er alm. Anerkendt, at det at udstille en selvbetjeningsløsning koster i snit 5 kr. pr henvendelse, hvilket er den reelle uafhængige kanalomkostning. Hvis man regner på samme måde mht. tlf. omkostninger, ville den også stige voldsomt i nogle kommuner. Altså må afsæt være den reelle kanalomkostning uafhængig af anvendelsesfrekvens.

I forhold til tallene fra KOMHEN, så kan de vel ikke helt sammenlignes - det er forskellige uger, der er talt i og forskellige emner - det er lidt som pærer og æbler eller?

Nej, det er ikke æbler og pærer. Der er så stor en datamængde i KOMHEN, at tallene er meget valide. Registreringsfaktor være en joker, men omvendt vil netop den store datamængde også kompensere for dette.

Vedrørende business case: Hvis der spares 20 % i år 1 af 275.000 henvendelser, så kan udgangspunktet i år 2, da ikke være 275.000 henvendelser - er de 55.000 henvendelser ikke væk?
Og lægger I ikke de 20% og 25% sammen, så besparelsen pludselig er 45%?

Det er 20 % år et, der flyttes fra den ene kanal til den anden. Da antallet af kontakter er konsistent år efter år, flyttes de samme 20 % året efter, og dertil tror vi, at man kan flytte yderligere 5 % år to, hvorfor vi opererer med kanalflyt på 25 %.